Skip to main content

Incentives

Paying the Caller​

As shown in the previous section the caller must be incentivized to poll the contract at regular intervals. So how is this done?

Time Incrementation​

In order to add time awareness to the contract a time value must be incremented by an external account.

One can think of this process like a virtual button which anyone is allowed to press. And while it costs money to press the button there is a bounty rewarded to the first person to press the button each day.

A more real world example is how lending protocols crowd source liquidation in a decentralized manner.

Lending protocols allow any user to liquidate any account by simply calling the contract function themselves and collecting a portion of the seized collateral.

Considerations​

Why not pay the caller in ETH?​

One might think that paying the caller in ETH would be appropriate since the caller must pay for the gas of polling the contract in ETH. But there are a few reasons this won't work.

Ethereum and Approval​

The ability for the protocol to have approved access to user accounts is critical to seamlessly transfer tokens at a future date.

While all standard ERC-20 tokens have a built-in process to facilitate approval, ETH does not. We could require a user to keep wrapped ETH in their account but this is not ideal from a UX perspective nor is it common for the average user to hold wrapped ethereum in their wallet.

No Oracles​

Another problem is that if we required one of the parties to pay their fees in ETH but the future transfer was an ERC-20 token we would need some sort of oracle to calculate the price of the ERC-20 vs ETH to have a proportional fee. But since having no oracles is a goal of the protocol this conversion won't work.

In kind fees​

As shown above paying the caller in ETH is not ideal. So the solution is to simply pay the fee in the same ERC-20 token as the subscription. In order to avoid oracles it will need to be a percentage of the overall transaction. But who pays this fee? The subscriber or the provider?

Problem with the Provider paying the Caller​

One might initially think that the provider should pay a portion of their earnings each period to the caller. This seems simpler since there is only one provider and they are the one's receiving all the funds.

But there is an attack vector if we go this route. Since we have no way of knowing the ownership of an ethereum address it is possible that combinations of the subscriber, provider and caller can be the same entity.

If the subscriber and caller are the same while the provider pays the fee to the caller there is a situation where the subscriber could sign up for a subscription and but not fund their account. When the transaction fails the fee would still be extracted from the provider and paid to the caller (who is also the subscriber.) If the fee is higher than the gas costs of signing up for the subscription then the malicious subscriber now has a method of extracting tokens from the provider.

Problems with the sender paying​

If the Provider can't be the one paying the fee then it must the subscriber. But this choice presents additional issues that must be considered.

The biggest issues revolve around failed transactions which we will go into in the next section.

The solution is having a fee balance where fees can be reserved and paid depending on the situation.